From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:16 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 13 11:13:17 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:17 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0001.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 13 15:13:44 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Jan 13 15:13:45 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0001.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:45 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 13 15:13:45 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 13 15:13:49 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:49 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 13 15:13:49 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:49 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 13 15:13:49 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:49 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:49 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:49 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:49 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 13 15:13:49 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:49 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:08 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:08 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0002.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 13 15:21:11 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:12 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Jan 13 15:21:12 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0002.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:12 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 13 15:21:12 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 13 15:21:12 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:12 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 13 15:21:12 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:12 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 13 15:21:12 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:12 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:12 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:12 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:12 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 13 15:21:12 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:12 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0003.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:43 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0003.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:44 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:25 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:26 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0004.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:27 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Jan 13 20:01:28 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0004.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:28 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 13 20:01:28 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 13 20:01:28 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:28 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 13 20:01:28 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:28 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 13 20:01:28 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:28 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:28 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:28 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:28 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 13 20:01:28 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:28 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0005.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0005.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 14 08:02:11 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 14 08:02:12 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:12 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 14 08:02:12 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:12 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 14 08:02:12 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:12 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:12 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:12 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:12 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 14 08:02:12 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:12 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:40 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:40 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:40 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 12:00:40 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 14 12:00:40 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:40 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 14 12:00:40 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 12:00:40 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 12:00:40 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 12:00:40 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 12:00:40 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:40 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 12:00:40 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:40 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0006.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0006.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:41 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:38 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:39 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:39 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 16:00:39 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 14 16:00:39 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:39 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 14 16:00:39 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 16:00:39 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 16:00:39 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 16:00:39 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 16:00:39 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:39 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 16:00:39 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:39 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0007.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0007.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:40 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:35 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:35 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:35 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 20:00:35 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 14 20:00:35 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0008.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0008.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:36 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:56 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:56 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 08:01:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 15 08:01:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0009.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0009.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:01:57 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:45 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:45 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:45 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 12:00:45 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 15 12:00:45 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:45 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 15 12:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 12:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 12:00:46 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 12:00:46 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 12:00:46 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 12:00:46 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 12:00:46 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0010.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0010.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:39 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:39 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:39 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 16:00:39 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 15 16:00:39 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:39 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 15 16:00:39 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 16:00:39 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 16:00:39 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 16:00:39 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0011.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0011.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:40 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0012.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0012.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 15 20:00:37 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:37 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 15 20:00:37 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:37 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:37 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:37 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:37 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 15 20:00:37 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:37 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0013.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0013.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 16 08:02:23 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 16 08:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 16 08:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 16 08:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:24 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:24 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:24 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 16 08:02:24 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:24 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0014.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0014.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 16 12:00:42 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 16 12:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 16 12:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 16 12:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 16 12:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:39 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:40 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:40 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 16:00:40 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0015.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0015.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:42 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:42 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:42 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 16 16:00:42 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:42 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0016.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:35 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0016.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:36 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:24 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:24 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 08:02:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 17 08:02:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 17 08:02:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 08:02:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 08:02:24 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 08:02:24 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 08:02:24 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:24 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 08:02:24 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:24 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0017.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0017.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:25 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:52 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0018.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0018.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:00:53 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:44 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:44 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 17 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 17 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 16:00:44 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 16:00:44 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 16:00:44 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 16:00:44 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0019.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0019.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:43 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0020.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0020.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 17 20:00:44 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 17 20:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0021.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:07 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Jan 18 08:04:08 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0021.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:08 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 18 08:04:08 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 18 08:04:08 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:08 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 18 08:04:08 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:08 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 18 08:04:08 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:08 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:08 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:08 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:08 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 18 08:04:08 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:08 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:56 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0022.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0022.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:57 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:58 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:58 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 18 12:00:58 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:00:58 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:16 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:16 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:16 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 16:01:16 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 18 16:01:16 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:16 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 18 16:01:16 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 16:01:16 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 16:01:16 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 16:01:16 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 16:01:16 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0023.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0023.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 18 16:01:18 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 18 16:01:19 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:19 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 18 16:01:19 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:19 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 18 16:01:19 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:19 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:19 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:19 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:19 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 18 16:01:19 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:19 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:45 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0024.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Jan 18 20:00:46 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0024.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:47 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 18 20:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 18 20:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 18 20:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 18 20:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 18 20:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:27 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0025.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Jan 19 08:04:29 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0025.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:29 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 19 08:04:29 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 19 08:04:29 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:29 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 19 08:04:29 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:29 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 19 08:04:29 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:29 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:29 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:29 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:29 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 19 08:04:29 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:29 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0026.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0026.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:55 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 19 12:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:32 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:32 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:33 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 16:02:33 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 19 16:02:33 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:33 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 19 16:02:33 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 16:02:33 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 16:02:33 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 16:02:33 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 16:02:33 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:33 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 16:02:33 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:33 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 16:02:34 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0027.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:34 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 16:02:34 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 16:02:34 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:34 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 16:02:34 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:34 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:34 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 16:02:34 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 19 16:02:34 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:34 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 19 16:02:34 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:35 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Jan 19 16:02:35 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0027.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:35 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 19 16:02:35 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 19 16:02:35 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:36 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 19 16:02:36 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:36 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 19 16:02:36 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:36 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:36 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:36 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:37 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 19 16:02:37 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:37 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0028.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 19 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0028.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:13 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:13 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:13 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0029.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 20 08:06:14 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:15 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Jan 20 08:06:17 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0029.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:17 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 20 08:06:17 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 20 08:06:17 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:17 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 20 08:06:18 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:18 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 20 08:06:18 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:18 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:18 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:18 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:18 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 20 08:06:18 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:18 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:48 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:48 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 12:01:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 20 12:01:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 20 12:01:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 12:01:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 12:01:48 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 12:01:48 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 12:01:48 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 12:01:48 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0030.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0030.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 20 12:01:49 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 20 12:01:50 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:50 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 20 12:01:50 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:50 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 20 12:01:50 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:50 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:50 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:50 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:50 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 20 12:01:50 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:01:51 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:44 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:44 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 20 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 20 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 16:00:44 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 16:00:44 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 16:00:44 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0031.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0031.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0032.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Jan 20 20:00:42 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0032.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:43 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 20 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 20 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 20 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 20 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 20 20:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0033.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:42 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0033.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:56 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:56 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 12:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 21 12:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 21 12:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 12:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 12:00:56 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 12:00:56 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 12:00:56 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 12:00:56 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 12:00:56 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0034.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0034.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:00:57 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0035.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 21 16:00:44 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0035.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:45 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0036.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0036.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:41 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:42 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 21 20:00:42 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:42 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0037.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:33 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:34 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 08:02:34 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 22 08:02:34 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:34 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 22 08:02:34 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:34 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Jan 22 08:02:34 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0037.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:34 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 22 08:02:34 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 22 08:02:34 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:34 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 22 08:02:34 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:36 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 22 08:02:36 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:36 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:36 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:36 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:36 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 22 08:02:36 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:36 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:44 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:45 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:45 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 12:00:45 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 22 12:00:45 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:45 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 22 12:00:45 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0038.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0038.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:46 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 22 12:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0039.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:08 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0039.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 22 16:01:09 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:10 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:10 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:10 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:10 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 22 16:01:10 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:10 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:05 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:05 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:05 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 20:01:05 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 22 20:01:05 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:05 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 22 20:01:05 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 20:01:05 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 20:01:05 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 20:01:05 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 20:01:05 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:05 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0040.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0040.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:06 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 22 20:01:07 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:07 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 22 20:01:07 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:07 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:07 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:07 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:07 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 22 20:01:07 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:07 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:26 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:26 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:27 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 08:02:27 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 23 08:02:27 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:27 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 23 08:02:27 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 08:02:27 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 08:02:27 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 08:02:27 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 08:02:27 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 08:02:27 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 08:02:27 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0041.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 08:02:27 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0041.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 23 08:02:28 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:29 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:46 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:46 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0042.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0042.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:32 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:32 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:32 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 16:01:32 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 23 16:01:32 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:32 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 23 16:01:32 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 16:01:32 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 16:01:32 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 16:01:32 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 16:01:32 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:32 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 16:01:32 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:32 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0043.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0043.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 23 16:01:33 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 23 16:01:34 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:34 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 23 16:01:34 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:34 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 23 16:01:34 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:34 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:34 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:34 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:34 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 23 16:01:34 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:34 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:45 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:45 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0044.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0044.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:46 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0045.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:02:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Jan 24 08:03:00 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0045.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:00 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 24 08:03:00 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 24 08:03:00 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 24 08:03:00 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 24 08:03:00 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:00 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:00 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 24 08:03:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:30 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:30 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:30 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 12:02:30 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 24 12:02:30 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:30 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 24 12:02:30 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 12:02:30 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 12:02:30 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 12:02:31 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 12:02:31 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:31 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 12:02:31 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:31 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 12:02:31 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0046.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:31 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 12:02:31 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 12:02:31 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:31 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 12:02:31 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:31 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:31 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 12:02:31 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 24 12:02:32 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:32 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 24 12:02:32 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:32 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Jan 24 12:02:32 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0046.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:32 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 24 12:02:32 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 24 12:02:33 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:33 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 24 12:02:33 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:33 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 24 12:02:33 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:33 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:33 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:34 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:34 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 24 12:02:34 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:34 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:11 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0047.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:12 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Jan 24 16:01:13 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0047.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:13 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 24 16:01:13 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 24 16:01:13 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:13 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 24 16:01:13 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:13 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 24 16:01:13 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:13 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:13 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:13 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:13 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 24 16:01:13 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:13 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:43 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:43 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:43 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 20:01:43 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 24 20:01:43 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:43 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 24 20:01:43 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 20:01:43 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 20:01:43 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 20:01:43 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 20:01:43 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:43 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 20:01:43 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:43 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 20:01:45 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0048.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:45 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 20:01:45 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 20:01:45 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:45 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 24 20:01:45 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:45 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:45 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 24 20:01:45 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 24 20:01:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 24 20:01:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:45 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Jan 24 20:01:45 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0048.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:45 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 24 20:01:46 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 24 20:01:46 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:46 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 24 20:01:46 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:46 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 24 20:01:46 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:46 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:46 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:46 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:46 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 24 20:01:46 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:46 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:52 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:52 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 08:01:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 25 08:01:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 25 08:01:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 08:01:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 08:01:52 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 08:01:52 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 08:01:52 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0049.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0049.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 25 08:01:53 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 25 08:01:54 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 25 08:01:54 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:54 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:54 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 25 08:01:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:01:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:52 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:52 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 12:00:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 25 12:00:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 25 12:00:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 12:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 12:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 12:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 12:00:53 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 12:00:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 12:00:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0050.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 12:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 12:00:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0050.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0051.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0051.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 25 16:00:51 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 25 16:00:52 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:52 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 25 16:00:52 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:52 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 25 16:00:52 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:52 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:52 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:52 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:52 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 25 16:00:52 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:00:52 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:47 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:47 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 20:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 25 20:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Jan 25 20:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 20:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 20:00:47 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 20:00:47 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0052.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0052.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:48 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:06 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:07 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:07 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 08:05:07 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 26 08:05:07 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:07 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 26 08:05:07 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 08:05:07 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 08:05:07 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 08:05:07 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 08:05:07 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:07 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 08:05:07 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:07 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 08:05:08 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0053.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:08 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 08:05:08 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 08:05:08 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:08 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 08:05:08 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:08 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:08 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 08:05:08 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 26 08:05:08 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:08 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 26 08:05:08 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:08 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Jan 26 08:05:10 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0053.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:10 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 26 08:05:10 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 26 08:05:10 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:10 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 26 08:05:10 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:10 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 26 08:05:10 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:10 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:10 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:10 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:11 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 26 08:05:11 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:11 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0054.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0054.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 26 12:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0055.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0055.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:46 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 26 16:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0056.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0056.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:05 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:05 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:05 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 08:06:05 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 27 08:06:05 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:05 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0057.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 08:06:06 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 27 08:06:07 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:07 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 27 08:06:07 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:07 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Jan 27 08:06:09 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0057.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:09 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 27 08:06:09 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 27 08:06:09 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:10 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 27 08:06:10 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:10 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 27 08:06:10 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:10 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:10 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:10 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:10 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 27 08:06:10 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:10 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:01:58 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0058.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:01:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Jan 27 12:02:00 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0058.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:01 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 27 12:02:01 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 27 12:02:01 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 27 12:02:01 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 27 12:02:01 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:01 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:01 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 27 12:02:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0059.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0059.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:46 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0060.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Jan 27 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0060.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:50 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:13 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:14 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 08:05:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 28 08:05:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 28 08:05:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 08:05:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 08:05:14 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 08:05:14 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 08:05:14 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:14 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 08:05:14 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:15 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 08:05:16 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0061.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:16 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 08:05:16 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 08:05:16 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:16 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 08:05:16 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:16 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:16 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 08:05:16 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 28 08:05:16 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:16 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 28 08:05:16 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:16 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Jan 28 08:05:18 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0061.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:18 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 28 08:05:18 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 28 08:05:18 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:18 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 28 08:05:18 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:18 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 28 08:05:18 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:18 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:18 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:18 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:18 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 28 08:05:18 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:19 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0062.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 12:01:48 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0062.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:49 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0063.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0063.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 28 16:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 28 16:00:48 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:48 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 28 16:00:48 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:48 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 28 16:00:48 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:48 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:48 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:48 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:48 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 28 16:00:48 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:48 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0064.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0064.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:49 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Jan 28 20:00:50 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:50 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Jan 28 20:00:50 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:50 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:50 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:50 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:50 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 28 20:00:50 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:50 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:51 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:51 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 08:06:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 29 08:06:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 29 08:06:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 08:06:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 08:06:52 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 08:06:52 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 08:06:52 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:52 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 08:06:52 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:52 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 08:06:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0065.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 08:06:53 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 08:06:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 08:06:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 08:06:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 29 08:06:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 29 08:06:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Jan 29 08:06:55 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0065.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:55 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 29 08:06:56 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 29 08:06:56 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:56 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 29 08:06:56 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:56 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 29 08:06:56 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:56 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:56 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:56 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:56 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 29 08:06:57 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:06:57 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0066.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 29 12:00:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0066.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 29 12:00:55 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0067.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0067.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 29 16:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:48 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:48 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:48 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:48 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 29 16:00:48 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:48 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0068.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0068.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 29 20:00:48 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 29 20:00:49 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:49 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Jan 29 20:00:49 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:49 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Jan 29 20:00:49 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:49 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:49 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:49 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:49 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 29 20:00:49 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:49 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:26 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:27 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:28 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 08:07:28 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 30 08:07:28 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:28 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 30 08:07:28 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 08:07:28 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 08:07:28 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 08:07:28 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 08:07:28 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:28 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 08:07:28 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:29 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 08:07:29 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0069.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:29 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 08:07:29 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 08:07:29 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:29 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 08:07:29 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:30 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:30 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 08:07:30 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 30 08:07:30 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:30 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 30 08:07:30 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:30 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Jan 30 08:07:36 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0069.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:36 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 30 08:07:36 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 30 08:07:36 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:37 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 30 08:07:37 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:37 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 30 08:07:37 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:37 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:38 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:38 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:39 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 30 08:07:40 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:07:40 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:35 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0070.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:36 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Jan 30 12:03:39 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0070.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:39 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 30 12:03:39 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 30 12:03:39 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:39 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 30 12:03:39 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:39 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 30 12:03:39 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:39 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:39 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:39 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:39 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 30 12:03:39 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:39 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0071.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 16:03:51 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 16:03:52 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:52 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 16:03:52 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:52 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:52 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 16:03:52 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 30 16:03:52 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:52 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 30 16:03:52 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:52 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Jan 30 16:03:53 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0071.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:53 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 30 16:03:53 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 30 16:03:53 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:53 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 30 16:03:53 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:53 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 30 16:03:53 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:53 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:53 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:53 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:53 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 30 16:03:53 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:03:53 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0072.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 20:01:58 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 20:01:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:01:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Jan 30 20:01:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:01:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:01:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Jan 30 20:01:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 30 20:01:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:01:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Jan 30 20:01:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:01:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Jan 30 20:02:01 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0072.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:01 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 30 20:02:01 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 30 20:02:01 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Jan 30 20:02:01 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Jan 30 20:02:01 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:01 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:01 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 30 20:02:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:23 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:23 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0073.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:24 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Jan 31 08:07:26 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0073.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:27 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 31 08:07:27 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 31 08:07:27 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:27 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 31 08:07:27 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:27 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 31 08:07:27 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:27 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:27 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:27 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:27 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 31 08:07:27 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:27 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:03:56 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:03:56 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:03:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 12:03:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0074.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 12:03:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 31 12:03:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:03:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 31 12:03:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:03:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Jan 31 12:04:00 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0074.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:00 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 31 12:04:00 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 31 12:04:00 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 31 12:04:00 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 31 12:04:00 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:00 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:00 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 31 12:04:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:01 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:01 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0075.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:02 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Jan 31 16:02:03 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0075.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:03 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 31 16:02:03 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 31 16:02:03 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:03 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 31 16:02:03 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:04 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 31 16:02:04 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:04 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:05 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:05 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:05 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 31 16:02:05 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:05 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:57 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:57 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 20:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 31 20:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Jan 31 20:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 20:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 20:00:57 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0076.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Jan 31 20:00:59 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0076.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:59 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 31 20:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 31 20:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Jan 31 20:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Jan 31 20:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 31 20:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:08 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:08 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:09 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 08:09:09 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 1 08:09:09 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:09 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 1 08:09:09 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 08:09:09 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 08:09:09 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 08:09:09 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 08:09:09 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:10 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 08:09:10 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:10 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 08:09:10 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0077.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:10 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 08:09:10 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 08:09:10 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:10 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 08:09:10 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:10 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:11 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 08:09:11 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 1 08:09:11 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:11 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 1 08:09:11 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:11 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Feb 1 08:09:12 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0077.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:12 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 1 08:09:12 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 1 08:09:12 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:12 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 1 08:09:12 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:12 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 1 08:09:13 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:13 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:13 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:13 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:13 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 1 08:09:13 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:13 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0078.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 12:02:25 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 1 12:02:26 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:26 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 1 12:02:26 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:26 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Feb 1 12:02:26 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0078.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:27 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 1 12:02:27 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 1 12:02:27 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:27 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 1 12:02:27 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:27 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 1 12:02:27 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:27 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:27 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:27 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:27 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 1 12:02:27 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:27 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:55 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0079.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0079.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:46 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0080.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0080.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:00:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:22 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:22 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:22 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 08:11:22 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 2 08:11:22 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 2 08:11:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 08:11:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 08:11:23 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 08:11:23 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 08:11:23 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 08:11:23 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 08:11:24 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0081.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:24 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 08:11:24 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 08:11:24 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:24 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 08:11:24 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:25 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:25 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 08:11:25 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 2 08:11:25 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:25 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 2 08:11:25 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:25 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Feb 2 08:11:31 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0081.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:31 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 2 08:11:31 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 2 08:11:31 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:31 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 2 08:11:31 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:32 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 2 08:11:32 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:32 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:32 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:32 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:32 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 2 08:11:32 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:11:32 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:31 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:32 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:32 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 12:02:32 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 2 12:02:32 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:32 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0082.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:33 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Feb 2 12:02:34 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0082.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:34 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 2 12:02:34 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 2 12:02:34 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:35 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 2 12:02:35 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:35 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 2 12:02:35 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:35 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:35 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:35 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:35 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 2 12:02:35 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:35 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:00 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:00 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 16:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 2 16:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 2 16:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 16:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 16:01:00 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 16:01:00 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 16:01:00 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:02 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 16:01:02 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:02 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0083.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0083.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:03 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:04 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 2 16:01:04 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:04 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0084.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 2 20:00:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0084.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:10:48 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:10:49 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:10:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 08:10:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 3 08:10:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:10:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 3 08:10:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 08:10:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 08:10:50 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 08:10:50 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 08:10:50 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:10:50 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 08:10:50 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:10:50 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 08:10:52 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0085.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:10:52 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 08:10:52 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 08:10:52 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:10:52 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 08:10:52 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:10:52 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:10:52 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 08:10:52 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 3 08:10:52 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:10:52 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 3 08:10:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:10:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Feb 3 08:10:59 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0085.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:10:59 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 3 08:10:59 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 3 08:11:00 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:11:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 3 08:11:00 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:11:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 3 08:11:00 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:11:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:11:00 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:11:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:11:01 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 3 08:11:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:11:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:20 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:20 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:20 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 12:02:20 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 3 12:02:20 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:20 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 3 12:02:20 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 12:02:20 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 12:02:20 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 12:02:20 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 12:02:20 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:20 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 12:02:20 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:20 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 12:02:21 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0086.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:21 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 12:02:21 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 12:02:21 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:21 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 12:02:21 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:21 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:21 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 12:02:21 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 3 12:02:21 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:21 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 3 12:02:21 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:22 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Feb 3 12:02:23 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0086.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:23 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 3 12:02:23 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 3 12:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 3 12:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 3 12:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:24 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:24 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:24 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 3 12:02:24 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:24 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:51 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:51 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0087.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0087.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:00:52 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0088.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:54 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0088.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 3 20:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:00:57 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:51 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:52 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 08:06:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 4 08:06:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 4 08:06:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 08:06:52 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 08:06:52 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 08:06:52 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 08:06:52 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:52 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 08:06:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 08:06:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0089.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 08:06:53 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 08:06:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 08:06:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:54 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 08:06:54 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 4 08:06:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 4 08:06:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Feb 4 08:06:57 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0089.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:58 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 4 08:06:58 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 4 08:06:58 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:58 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 4 08:06:58 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:58 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 4 08:06:59 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:59 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:59 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:59 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:06:59 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 4 08:07:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0090.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:23 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 12:02:24 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 4 12:02:24 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:24 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 4 12:02:24 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:24 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Feb 4 12:02:25 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0090.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:25 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 4 12:02:25 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 4 12:02:25 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:25 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 4 12:02:25 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:25 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 4 12:02:25 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:25 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:25 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:25 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:25 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 4 12:02:25 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:25 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0091.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 16:01:02 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 4 16:01:05 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:05 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 4 16:01:05 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:05 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Feb 4 16:01:06 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0091.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:06 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 4 16:01:06 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 4 16:01:06 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:06 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 4 16:01:06 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:06 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 4 16:01:06 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:06 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:06 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:06 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:06 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 4 16:01:06 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:06 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:56 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:57 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0092.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0092.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:00:58 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:17 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:18 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:18 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 08:07:18 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 5 08:07:18 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:18 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 5 08:07:18 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 08:07:18 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 08:07:18 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 08:07:18 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 08:07:19 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:19 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 08:07:19 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:19 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 08:07:19 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0093.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:19 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 08:07:19 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 08:07:19 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:19 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 08:07:19 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:19 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:19 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 08:07:20 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 5 08:07:20 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:20 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 5 08:07:20 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:20 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Feb 5 08:07:22 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0093.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:22 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 5 08:07:23 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 5 08:07:23 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:23 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 5 08:07:23 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:23 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 5 08:07:23 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:23 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:24 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:24 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:24 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 5 08:07:24 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:24 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:24 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:24 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 12:02:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 5 12:02:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 5 12:02:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 12:02:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0094.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:26 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Feb 5 12:02:28 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0094.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:28 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 5 12:02:28 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 5 12:02:28 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:28 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 5 12:02:28 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:28 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 5 12:02:28 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:28 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:28 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:28 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:28 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 5 12:02:28 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:28 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:00:59 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:00:59 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 16:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 5 16:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 5 16:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0095.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0095.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0096.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0096.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:53 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 5 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 5 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 5 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 5 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 5 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:19 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:21 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:21 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 08:12:22 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 6 08:12:22 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 6 08:12:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 08:12:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 08:12:24 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 08:12:24 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 08:12:25 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:25 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 08:12:25 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:25 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 08:12:27 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0097.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 08:12:28 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 08:12:28 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:29 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 08:12:29 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:29 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:29 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 08:12:29 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 6 08:12:29 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:29 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 6 08:12:30 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:30 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Feb 6 08:12:38 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0097.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:38 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 6 08:12:38 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 6 08:12:39 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:39 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 6 08:12:40 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 6 08:12:41 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:41 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:41 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:42 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 6 08:12:42 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:12:42 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:21 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:21 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:21 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 12:02:21 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 6 12:02:21 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:21 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0098.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:22 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Feb 6 12:02:24 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0098.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:24 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 6 12:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 6 12:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 6 12:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 6 12:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:24 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:24 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:24 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:24 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 6 12:02:24 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:24 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:00:57 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0099.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0099.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 6 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 6 16:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 6 16:01:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:53 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:53 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 6 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 6 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 20:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 20:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0100.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0100.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:18:18 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:18:21 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:18:22 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 08:18:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 7 08:18:23 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:18:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 7 08:18:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 08:18:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 08:18:25 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 08:18:25 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 08:18:25 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:18:25 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 08:18:26 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:18:26 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 08:18:28 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0101.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:18:30 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 08:18:30 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 08:18:30 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:18:30 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 08:18:31 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:18:31 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:18:31 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 08:18:31 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 7 08:18:32 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:18:32 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 7 08:18:32 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:18:32 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Feb 7 08:19:10 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0101.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:19:11 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 7 08:19:11 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 7 08:19:11 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:19:11 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 7 08:19:12 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:19:12 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 7 08:19:13 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:19:13 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:19:13 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:19:15 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:19:15 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 7 08:19:18 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:19:18 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:02:56 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:02:56 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:02:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 12:02:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 7 12:02:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:02:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 7 12:02:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 12:02:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 12:02:58 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0102.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:02:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Feb 7 12:03:01 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0102.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:01 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 7 12:03:01 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 7 12:03:01 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 7 12:03:01 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 7 12:03:01 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:01 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:01 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 7 12:03:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0103.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 16:00:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0103.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0104.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0104.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:00:59 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 7 20:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:00 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:19:48 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:19:49 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:19:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 08:19:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 8 08:19:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:19:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 8 08:19:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 08:19:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 08:19:50 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 08:19:50 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 08:19:50 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:19:51 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 08:19:51 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:19:52 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 08:19:55 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0105.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:19:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 08:19:56 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 08:19:56 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:19:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 08:19:57 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:19:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:19:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 08:19:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 8 08:19:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:19:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 8 08:19:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:19:59 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Feb 8 08:20:13 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0105.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:20:13 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 8 08:20:14 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 8 08:20:14 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:20:14 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 8 08:20:14 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:20:15 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 8 08:20:15 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:20:15 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:20:15 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:20:15 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:20:15 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 8 08:20:15 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:20:16 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:48 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0106.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Feb 8 12:02:51 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0106.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:51 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 8 12:02:51 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 8 12:02:51 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:51 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 8 12:02:51 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:52 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 8 12:02:52 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:52 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:53 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:53 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:54 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 8 12:02:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:02:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:03 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:03 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:03 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 16:01:03 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 8 16:01:03 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:03 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 8 16:01:04 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 16:01:04 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 16:01:04 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 16:01:04 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 16:01:04 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:04 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 16:01:04 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:04 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 16:01:06 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0107.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:06 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 16:01:06 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 16:01:06 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:06 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 16:01:06 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:06 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0107.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:07 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0108.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0108.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 8 20:00:53 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:54 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 8 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:00:54 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:04 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:04 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:04 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 08:08:04 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 9 08:08:05 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:05 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 9 08:08:05 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 08:08:05 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 08:08:06 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 08:08:06 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 08:08:06 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:06 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 08:08:07 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:07 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 08:08:07 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0109.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:08 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 08:08:08 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 08:08:08 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:08 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 08:08:09 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:09 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:09 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 08:08:09 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 9 08:08:09 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:09 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 9 08:08:10 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:10 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Feb 9 08:08:14 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0109.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:15 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 9 08:08:15 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 9 08:08:15 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:15 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 9 08:08:15 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:15 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 9 08:08:15 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:16 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:16 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:16 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:16 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 9 08:08:16 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:08:17 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:37 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0110.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:38 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Feb 9 12:02:40 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0110.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:40 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 9 12:02:40 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 9 12:02:40 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 9 12:02:41 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 9 12:02:41 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:41 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:41 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:41 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 9 12:02:41 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:02:41 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0111.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0111.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:08 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 9 16:01:09 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:09 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:00:59 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0112.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0112.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:01 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:01 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 9 20:01:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:16:27 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:16:29 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:16:30 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 08:16:33 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 10 08:16:34 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:16:35 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 10 08:16:35 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 08:16:36 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 08:16:36 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 08:16:37 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 08:16:38 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:16:38 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 08:16:38 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:16:39 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 08:16:41 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0113.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:16:42 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 08:16:42 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 08:16:42 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:16:43 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 08:16:43 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:16:44 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:16:46 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 08:16:46 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 10 08:16:46 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:16:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 10 08:16:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:16:47 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Feb 10 08:16:58 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0113.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:16:59 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 10 08:17:00 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 10 08:17:00 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:17:00 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 10 08:17:01 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:17:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 10 08:17:01 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:17:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:17:01 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:17:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:17:02 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 10 08:17:02 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:17:02 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:11 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:11 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 12:03:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 10 12:03:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 10 12:03:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 12:03:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 12:03:12 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 12:03:12 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 12:03:12 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:12 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 12:03:12 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:12 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 12:03:13 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0114.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:13 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 12:03:13 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 12:03:13 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:13 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 12:03:13 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:13 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:13 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 12:03:13 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 10 12:03:13 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:13 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 10 12:03:13 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:13 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Feb 10 12:03:17 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0114.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:17 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 10 12:03:17 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 10 12:03:17 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:17 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 10 12:03:17 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:17 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 10 12:03:18 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:18 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:18 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:18 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:18 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 10 12:03:18 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:18 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0115.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 16:01:01 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0115.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:02 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:00 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:00 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 20:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 10 20:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Feb 10 20:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 20:01:00 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 20:01:00 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 20:01:00 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 20:01:00 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0116.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0116.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:00 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:01 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 08:12:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 11 08:12:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 11 08:12:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 08:12:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 08:12:01 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 08:12:02 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 08:12:02 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:02 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 08:12:02 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:02 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 08:12:03 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0117.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:03 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 08:12:04 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 08:12:04 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:04 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 08:12:04 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:04 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:04 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 08:12:04 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 11 08:12:04 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:04 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 11 08:12:05 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:05 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Feb 11 08:12:07 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0117.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:08 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 11 08:12:08 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 11 08:12:08 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:08 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 11 08:12:08 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:08 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 11 08:12:08 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:09 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:09 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:09 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:09 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 11 08:12:09 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:09 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:18 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0118.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:19 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Feb 11 12:02:22 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0118.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:22 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 11 12:02:22 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 11 12:02:22 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:22 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 11 12:02:22 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:22 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 11 12:02:22 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:22 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:22 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:22 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:22 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 11 12:02:22 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:22 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0119.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0119.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 11 16:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 11 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 11 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 11 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:58 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:58 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:58 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 11 16:00:58 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:00:58 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0120.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sat Feb 11 20:00:50 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:51 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sat Feb 11 20:00:51 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0120.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:51 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 11 20:00:51 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 11 20:00:51 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:51 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sat Feb 11 20:00:51 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:51 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sat Feb 11 20:00:51 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:51 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:51 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:51 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:51 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 11 20:00:51 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:51 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:24 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:25 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 08:08:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 12 08:08:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 12 08:08:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 08:08:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 08:08:25 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 08:08:25 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 08:08:25 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:25 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 08:08:25 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:25 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 08:08:26 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0121.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 08:08:27 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 08:08:27 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 08:08:27 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:28 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 08:08:28 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 12 08:08:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 12 08:08:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Feb 12 08:08:31 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0121.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:31 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 12 08:08:31 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 12 08:08:31 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:31 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 12 08:08:31 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:31 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 12 08:08:32 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:32 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:32 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:32 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:32 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 12 08:08:32 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:08:32 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:25 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0122.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:26 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:27 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 12:02:27 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 12 12:02:27 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:27 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 12 12:02:27 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Feb 12 12:02:29 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0122.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:29 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 12 12:02:29 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 12 12:02:30 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:30 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 12 12:02:30 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:30 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 12 12:02:30 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:30 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:30 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:30 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:30 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 12 12:02:30 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:30 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0123.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0123.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:58 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 12 16:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:00:59 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0124.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0124.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 12 20:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 12 20:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Sun Feb 12 20:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Sun Feb 12 20:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:57 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:57 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:57 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:57 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 12 20:00:57 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:00:57 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:23 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:24 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:24 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 08:15:25 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 13 08:15:26 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:26 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 13 08:15:26 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 08:15:26 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 08:15:26 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 08:15:27 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 08:15:27 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 08:15:27 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 08:15:30 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0125.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:30 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 08:15:30 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 08:15:30 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:30 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 08:15:30 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:30 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:30 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 08:15:31 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 13 08:15:31 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:31 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 13 08:15:31 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:33 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Feb 13 08:15:41 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0125.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:41 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 13 08:15:41 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 13 08:15:41 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 13 08:15:42 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:42 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 13 08:15:42 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:42 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:42 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:42 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:42 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 13 08:15:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:15:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:37 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0126.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:38 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:39 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 12:02:39 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 13 12:02:39 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:39 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 13 12:02:39 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:39 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Feb 13 12:02:40 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0126.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:40 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 13 12:02:40 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 13 12:02:41 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:41 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 13 12:02:41 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:42 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 13 12:02:42 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:42 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:42 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:42 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:43 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 13 12:02:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:02:43 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0127.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0127.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:14 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 13 16:01:15 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 13 16:01:15 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:15 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 13 16:01:15 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:15 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 13 16:01:15 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:15 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:15 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:15 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:15 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 13 16:01:15 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:15 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:53 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0128.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Mon Feb 13 20:00:56 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0128.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:56 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 13 20:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 13 20:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Mon Feb 13 20:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Mon Feb 13 20:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:56 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 13 20:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:00:56 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:17 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:20 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:20 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 08:17:20 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 14 08:17:20 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:20 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 14 08:17:20 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 08:17:22 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 08:17:22 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 08:17:22 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 08:17:22 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:22 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 08:17:22 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 08:17:25 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0129.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 08:17:27 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 08:17:27 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 08:17:28 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:28 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:28 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 08:17:28 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 14 08:17:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:29 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 14 08:17:30 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:30 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Feb 14 08:17:43 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0129.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:43 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 14 08:17:43 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 14 08:17:44 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:44 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 14 08:17:44 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:45 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 14 08:17:46 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:46 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:46 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:46 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:46 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 14 08:17:46 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:17:46 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:02:55 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:02:55 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:02:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 12:02:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 14 12:02:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:02:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 14 12:02:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 12:02:55 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 12:02:55 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 12:02:55 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 12:02:55 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:02:55 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 12:02:55 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:02:55 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 12:02:56 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0130.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:02:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 12:02:56 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 12:02:56 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:02:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 12:02:56 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:02:56 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:02:56 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 12:02:56 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 14 12:02:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:02:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 14 12:02:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:02:56 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Feb 14 12:03:00 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0130.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:00 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 14 12:03:00 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 14 12:03:01 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 14 12:03:01 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 14 12:03:01 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:01 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:01 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:01 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 14 12:03:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:01 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:18 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:18 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:18 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 16:01:18 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 14 16:01:18 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:18 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0131.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0131.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:19 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:00 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0132.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0132.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 14 20:01:01 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:02 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Tue Feb 14 20:01:02 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:02 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Tue Feb 14 20:01:02 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:02 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:02 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:02 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:02 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 14 20:01:02 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:02 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:08 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:13 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:13 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 08:23:13 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 15 08:23:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 15 08:23:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 08:23:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 08:23:15 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 08:23:15 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 08:23:15 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:15 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 08:23:16 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:16 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 08:23:22 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0133.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:22 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 08:23:22 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 08:23:23 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 08:23:23 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:24 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:25 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 08:23:27 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 15 08:23:27 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 15 08:23:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:28 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Feb 15 08:23:46 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0133.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:46 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 15 08:23:47 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 15 08:23:47 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:49 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 15 08:23:49 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:49 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 15 08:23:49 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:50 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:50 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:50 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:50 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 15 08:23:51 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:23:51 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:47 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:48 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 12:04:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 15 12:04:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 15 12:04:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 12:04:48 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 12:04:48 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 12:04:48 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 12:04:48 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 12:04:48 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:48 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 12:04:49 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0134.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 12:04:49 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 12:04:49 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 12:04:49 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:49 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:49 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 12:04:49 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 15 12:04:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 15 12:04:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:49 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Feb 15 12:04:51 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0134.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:51 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 15 12:04:51 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 15 12:04:51 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:51 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 15 12:04:51 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:51 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 15 12:04:52 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:52 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:52 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:52 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:52 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 15 12:04:52 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:04:52 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:17 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:22 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:22 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 16:01:22 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 15 16:01:22 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:22 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 15 16:01:22 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 16:01:22 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 16:01:22 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 16:01:22 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 16:01:22 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:22 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 16:01:22 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:22 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 16:01:22 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0135.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:22 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 16:01:23 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 16:01:23 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 16:01:23 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:23 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:23 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 16:01:23 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 15 16:01:24 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:24 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 15 16:01:24 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:24 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Feb 15 16:01:24 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0135.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:24 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 15 16:01:24 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 15 16:01:24 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:24 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 15 16:01:25 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:25 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 15 16:01:25 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:25 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:25 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:25 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:25 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 15 16:01:25 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:25 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:54 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:54 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 19:27:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 15 19:27:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 15 19:27:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 19:27:54 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 19:27:54 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 19:27:54 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 19:27:54 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:54 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 19:27:54 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:54 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0136.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0136.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 15 19:27:55 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 15 19:27:57 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:57 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 15 19:27:57 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:58 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 15 19:27:58 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:58 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:58 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:58 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:58 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 15 19:27:58 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:27:58 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:13 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:13 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:13 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 20:12:13 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 15 20:12:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Wed Feb 15 20:12:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 20:12:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 20:12:14 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 20:12:14 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 20:12:14 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:14 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 20:12:14 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:14 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 20:12:14 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0137.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:15 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 20:12:15 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 20:12:15 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:15 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Wed Feb 15 20:12:15 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:15 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:15 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Wed Feb 15 20:12:15 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 15 20:12:15 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:15 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Wed Feb 15 20:12:15 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:15 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Wed Feb 15 20:12:22 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0137.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:22 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 15 20:12:22 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 15 20:12:22 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:22 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Wed Feb 15 20:12:22 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:23 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Wed Feb 15 20:12:23 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:23 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:23 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:23 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:24 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 15 20:12:24 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:12:24 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:11 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:13 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:13 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 16 08:42:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 16 08:42:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Thu Feb 16 08:42:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 16 08:42:14 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 16 08:42:14 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 16 08:42:14 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 16 08:42:15 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:15 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 16 08:42:15 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:15 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 16 08:42:26 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0138.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:26 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 16 08:42:26 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 16 08:42:27 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:27 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Thu Feb 16 08:42:28 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:28 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:28 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Thu Feb 16 08:42:29 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 16 08:42:30 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:30 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Thu Feb 16 08:42:30 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:30 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Thu Feb 16 08:42:44 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0138.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:44 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 16 08:42:44 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 16 08:42:45 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:45 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Thu Feb 16 08:42:45 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:45 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Thu Feb 16 08:42:47 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:47 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:47 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:47 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:47 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 16 08:42:48 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:42:48 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 17:17:57 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] mxDateTime and Zope References: <53149007326.20020828093919@publisher.de> Message-ID: <3D737315.7040401@lemburg.com> Ulrich Wisser wrote: > Hello, > > after more investigation I found that mxDateTime has > replaced the Zope builtin DateTime module. I belive, but > did not verify, that the option --with-zope to the configure > script did the trick. Anyway, this led to the fact that > DateTime could no longer be used in DTML and PageTemplates. > After restoring the original DateTime everything works fine. > > Any idea why that is so and why the option --with-zope > exists if it doesn't work? I am not aware of such an option in distutils. You should install the mx base package directly into lib/python: python setup.py install --install-lib=zopedir/lib/python --install-data=zopedir/lib/python (with zopedir replaced by the Zope instance directory) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Mon Sep 2 20:12:20 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] The mxDateTime rpms are non-compliant with the Linux Standards Base References: <3.0.5.16.20020819131710.3c8f6c86@cpcug.org> <3.0.5.16.20020831181102.447fc84e@cpcug.org> Message-ID: <3D739BF4.4090009@lemburg.com> Stanley A. Klein wrote: > I don't know about the distutils default. Perhaps all other Python rpm > packagers change from the default to /usr/share during rpm packaging. I think you're mixing something up here: /usr/share is for code and data which can be shared between platforms (e.g. in an NFS environment). The /usr/local default stems from the fact that a manually installed Python version always installs into /usr/local per default and that's what we are using to build the RPMs. Now, perhaps you are right in that the RPMs we ship should install into /usr/share for the doc files and /use/lib/pythonX.X/site-packages for the rest. > I have Python 1.5 and 2.1, wxPython, and (I think) some other packages > installed on my system. All of them automatically install in /usr/ahare. > To the best of my knowledge that is where Python packagers are supposed to > put their packages. These packages are packaged in compliance with the > Linux Standards Base specification, which (I understand) may have clarified > or modified for Linux the definition of what is supposed to go into > /usr/share versus /usr/local. (Essentially, all downloaded packages or > those supplied with distributions go into /usr/share. I don't recall the > purpose assigned to /usr/local, except that it may be reserved for uniquely > local packages developed by the system administrator.) I don't believe that's correct... /usr/local is reserved for applications which do not come with your OS distribution. Other OSes such as Solaris use /opt/local for the same thing. It just happens that Python has become so popular that the default "installation" today is the one that comes with the OS distribution and not the one you built youself. > mxDateTime is the only Python package installed on my system that I had to > fix because it installed in /usr/local. (I fixed it by putting a link in > the appropriate site-packages directory in the /usr/share tree.) And that's the correct fix. I think we'll move to /usr for the upcoming 2.1 release... That should also make it possible to upgrade RedHat's version of egenix-mx-base (they call it mx-base for some reason). PS: Please sign up to the mailing list before posting. Otherwise all messages will be upheld for moderator approval. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at egenix.com Thu Sep 5 12:09:52 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> Message-ID: <3D771F60.3040005@lemburg.com> Mike C. Fletcher wrote: > I've been poking at this problem for a while now, basically, my attempts > always fail with this error: > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttools.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.def > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1b74):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x1bf0):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x2fb4):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.text+0x3030):mxte.c: > undefined reference to `_imp__mxTagTable_Type' > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > Which, is just about what VC++6 also complains about as well: > Creating library > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.lib > and object > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTools.exp > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported Is this the latest beta you are testing here ? http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html It should be compatible to CYGWIN since Steve Holden has done a lot of testing on that platform. > Now, if I understand this problem correctly, the __declspec( dllexport ) > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > somehow making mxTagTable_Type wind up mangled as if it were a > dll-loaded function within mxte.c instead of a locally-defined but > exported one? VC++ seems able to work about it, but not MingW32. > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > problem would be. All discussions I can find on the web about it seem > to assume it's such an obvious fix that there's no point describing it > :o/ . > > Any suggestions welcome, > Mike > _______________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://members.rogers.com/mcfletch/ > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From sholden at holdenweb.com Thu Sep 5 08:06:18 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <00c901c254cc$430444d0$6300000a@holdenweb.com> I can confirm that 2.1.0b5 compiles successfully builds and installs on my Cygwin/Win2k platform - just downloaded the source from the link Marc-Andre provided. Not sure what the problem is here, but I know that the original difficulty was ironed out after we found that external symbol definitions weren't making it through. I'm not really a C/C++ guy myself, but M-A was a tremendous help. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- ----- Original Message ----- From: "M.-A. Lemburg" To: "Mike C. Fletcher" Cc: "egenix-users" Sent: Thursday, September 05, 2002 5:09 AM Subject: Re: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? > Mike C. Fletcher wrote: > > I've been poking at this problem for a while now, basically, my attempts > > always fail with this error: > > > > c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxtexttool s.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxbmse.o > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.def > > -LC:\bin\lang\py22\libs -L/lib -lpython22 -o > > build\lib.win32-2.2\mx\TextTools\mxTextTools\mxTextTools.pyd > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1b74):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x1bf0):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x2fb4):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxte.o(.te xt+0x3030):mxte.c: > > undefined reference to `_imp__mxTagTable_Type' > > collect2: ld returned 1 exit status > > error: command 'gcc' failed with exit status 1 > > > > Which, is just about what VC++6 also complains about as well: > > Creating library > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.lib > > and object > > build\temp.win32-2.2\Release\mx\TextTools\mxTextTools\mxTextTools\mxTextTool s.exp > > > > LINK : warning LNK4049: locally defined symbol "_mxTagTable_Type" imported > > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.htm l > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > > > Now, if I understand this problem correctly, the __declspec( dllexport ) > > stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type is > > somehow making mxTagTable_Type wind up mangled as if it were a > > dll-loaded function within mxte.c instead of a locally-defined but > > exported one? VC++ seems able to work about it, but not MingW32. > > > > I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the > > problem would be. All discussions I can find on the web about it seem > > to assume it's such an obvious fix that there's no point describing it > > :o/ . > > > > Any suggestions welcome, > > Mike > > _______________________________________ > > Mike C. Fletcher > > Designer, VR Plumber, Coder > > http://members.rogers.com/mcfletch/ > > > > > > > > _______________________________________________________________________ > > eGenix.com User Mailing List http://www.egenix.com/ > > http://lists.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > _______________________________________________________________________ > eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... > Python Consulting: http://www.egenix.com/ > Python Software: http://www.egenix.com/files/python/ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users > > From mcfletch at rogers.com Thu Sep 5 10:46:12 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> Message-ID: <3D776024.7030800@rogers.com> The package does compile w/out problem for the _Cygwin port of Python_, but what I'm trying to do is to compile it with the Mingw32 extensions to GCC so that the resulting binaries can be used with the "regular" ActiveState/PythonLabs distributions (compiled with VC++). I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin version working, but given my tests here, I'm assuming he was working on the pure-Cygwin version, not the Mingw32 version (or that I'm missing something about something :) ). Oh, it's the latest beta-5, no alterations, just unzipping and running setup.py Have fun all, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: > >> I've been poking at this problem for a while now, basically, my >> attempts always fail with this error: >> >> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s ... >> undefined reference to `_imp__mxTagTable_Type' >> collect2: ld returned 1 exit status >> error: command 'gcc' failed with exit status 1 ... > Is this the latest beta you are testing here ? > > http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html > > > It should be compatible to CYGWIN since Steve Holden has done a lot > of testing on that platform. > >> Now, if I understand this problem correctly, the __declspec( dllexport >> ) stuff that's defined in mxTextTools.h and mxh.h for mxTagTable_Type >> is somehow making mxTagTable_Type wind up mangled as if it were a >> dll-loaded function within mxte.c instead of a locally-defined but >> exported one? VC++ seems able to work about it, but not MingW32. >> >> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to the >> problem would be. All discussions I can find on the web about it seem >> to assume it's such an obvious fix that there's no point describing it >> :o/ . >> >> Any suggestions welcome, >> Mike ... From mal at egenix.com Thu Sep 5 20:03:07 2002 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> Message-ID: <3D778E4B.4010704@lemburg.com> Mike C. Fletcher wrote: > The package does compile w/out problem for the _Cygwin port of Python_, > but what I'm trying to do is to compile it with the Mingw32 extensions > to GCC so that the resulting binaries can be used with the "regular" > ActiveState/PythonLabs distributions (compiled with VC++). I'm pretty sure that he used CYGWIN all the way. Why would you want to build using MinGW32 ? eGenix.com provides the binaries you need as installers for Windows. > I've asked Steve to confirm whether he's got the Mingw32 or the Cygwin > version working, but given my tests here, I'm assuming he was working on > the pure-Cygwin version, not the Mingw32 version (or that I'm missing > something about something :) ). > > Oh, it's the latest beta-5, no alterations, just unzipping and running > setup.py > > Have fun all, > Mike > > M.-A. Lemburg wrote: > >> Mike C. Fletcher wrote: >> >>> I've been poking at this problem for a while now, basically, my >>> attempts always fail with this error: >>> >>> c:\bin\cygwin\bin\gcc.exe -mno-cygwin -mdll -static -s >> > ... > >>> undefined reference to `_imp__mxTagTable_Type' >>> collect2: ld returned 1 exit status >>> error: command 'gcc' failed with exit status 1 >> > ... > >> Is this the latest beta you are testing here ? >> >> http://lists.egenix.com/mailman-archives/egenix-users/2002-August/000078.html >> >> >> It should be compatible to CYGWIN since Steve Holden has done a lot >> of testing on that platform. >> >>> Now, if I understand this problem correctly, the __declspec( >>> dllexport ) stuff that's defined in mxTextTools.h and mxh.h for >>> mxTagTable_Type is somehow making mxTagTable_Type wind up mangled as >>> if it were a dll-loaded function within mxte.c instead of a >>> locally-defined but exported one? VC++ seems able to work about it, >>> but not MingW32. >>> >>> I'm not really a C/C++ guy, so I'm not sure what the _solution_ to >>> the problem would be. All discussions I can find on the web about it >>> seem to assume it's such an obvious fix that there's no point >>> describing it :o/ . >>> >>> Any suggestions welcome, >>> Mike >> > ... > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mcfletch at rogers.com Thu Sep 5 14:24:21 2002 From: mcfletch at rogers.com (Mike C. Fletcher) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> Message-ID: <3D779345.9030509@rogers.com> Well, sure, but not for the non-recursive rewrite (which I eventually want to build for people, I'm just starting with the unmodifed package to isolate any potential problems from my modifications). Using Mingw32 would let me build and distribute binaries of the non-recursive version for use with SimpleParse. No other major conspiracies in the wing, Mike M.-A. Lemburg wrote: > Mike C. Fletcher wrote: ... > I'm pretty sure that he used CYGWIN all the way. > > Why would you want to build using MinGW32 ? eGenix.com provides > the binaries you need as installers for Windows. ... From sholden at holdenweb.com Thu Sep 5 20:24:33 2002 From: sholden at holdenweb.com (Steve Holden) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] Anyone successfully compiled mxTextTools beta5 with MingW32? References: <3D6C50FF.7080505@rogers.com> <3D771F60.3040005@lemburg.com> <3D776024.7030800@rogers.com> <3D778E4B.4010704@lemburg.com> <3D779345.9030509@rogers.com> Message-ID: <01c301c25533$65650ed0$6300000a@holdenweb.com> [Mike C. Fletcher]= > Well, sure, but not for the non-recursive rewrite (which I eventually > want to build for people, I'm just starting with the unmodifed package > to isolate any potential problems from my modifications). Using Mingw32 > would let me build and distribute binaries of the non-recursive version > for use with SimpleParse. > > No other major conspiracies in the wing, > Mike > > M.-A. Lemburg wrote: > > Mike C. Fletcher wrote: > ... > > I'm pretty sure that he used CYGWIN all the way. > > > > Why would you want to build using MinGW32 ? eGenix.com provides > > the binaries you need as installers for Windows. > ... Just wanted to confirm that I did indeed only use pure Cygwin. I know that someone recently (maybe in the last three months) has managed to compile Python using MingW32 (maybe it was you? :-) I presume that you are interested in using MingW32 to avoid the need to purchase VC++ or similar. Good luck! regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming pydish.holdenweb.com/pwp/ Previous .sig file retired to www.homeforoldsigs.com ----------------------------------------------------------------------- From nthomas at cise.ufl.edu Tue Sep 10 04:29:23 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] DateTime bus error on Solaris Message-ID: <20020910072923.GA2087@cise.ufl.edu> I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running Solaris 8 (SunOS 5.8). When I run any program that uses DateTime (or indeed, any module that calls it) I get the following error: $ python foo.py zsh: bus error python foo.py In fact, any program with the line from mx.DateTime import * or import mx.DateTime causes this to happen. Has anyone else experienced this problem? thanks, thomas P.S. Proxy, Tools, and TextTools all seem to work okay. -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Tue Sep 10 04:59:28 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020910075928.GA3494@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > running Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that > calls it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py A bit of digging on Google tells me that it might possibly be a problem with byte alignment on Sparc. I would like to check this, and pass the "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From daniel.naber at t-online.de Thu Sep 12 04:01:11 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] BeeDict memory usage Message-ID: <200209120301.11205@danielnaber.de> Hi, I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ recover=0, autocommit=1, validate=0) self.table is then used to save quite some (nested) data, i.e. lists and dictionaries. This works well, but there's one problem: too much memory is used when adding data. I had hoped that "on-disk" means something like: save the data to disk if there's a flush() or commit() call so that the data doesn't take up memory. I tried that, but it doesn't help (actually commit()ing after adding a certain amount of data will leave the index incomplete in the end). Does anybody have an idea how to save memory when adding data? Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 13:53:50 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> Message-ID: <3D85B83E.5040306@lemburg.com> Daniel Naber wrote: > Hi, > > I'm using BeeDict (egenix-mx-base-2.1.0b2) with the following code: > > self.table = BeeDict(self.db_name, min_recordsize=0, readonly=0, \ > recover=0, autocommit=1, validate=0) > > self.table is then used to save quite some (nested) data, i.e. lists and > dictionaries. This works well, but there's one problem: too much memory is > used when adding data. I had hoped that "on-disk" means something like: > save the data to disk if there's a flush() or commit() call so that the > data doesn't take up memory. I tried that, but it doesn't help (actually > commit()ing after adding a certain amount of data will leave the index > incomplete in the end). > > Does anybody have an idea how to save memory when adding data? BeeDicts keep an internal cache which could be the cause of the memory footprint you are seeing. You can explicitly clear the cache by calling .free_cache(). Perhaps it would be a good idea to have .flush() also free the cache ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 17:14:09 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85B83E.5040306@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> Message-ID: <200209161614.10077@danielnaber.de> On Monday 16 September 2002 12:53, you wrote: > BeeDicts keep an internal cache which could be the cause of the > memory footprint you are seeing. You can explicitly clear the > cache by calling .free_cache(). This helps with the memory usage, but now I've got the same problem as before, when I called flush(): the generated index files are smaller and some information is missing. I'm trying to write a search engine, and the index that calls free_cache() on every 50th file gets less matches when searching (yes, the call to free_cache() is really the only difference in the program). Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Mon Sep 16 18:53:00 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D85B83E.5040306@lemburg.com> <200209161614.10077@danielnaber.de> Message-ID: <3D85FE5C.2010402@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 12:53, you wrote: > > >>BeeDicts keep an internal cache which could be the cause of the >>memory footprint you are seeing. You can explicitly clear the >>cache by calling .free_cache(). > > > This helps with the memory usage, but now I've got the same problem as > before, when I called flush(): the generated index files are smaller and > some information is missing. I'm trying to write a search engine, and the > index that calls free_cache() on every 50th file gets less matches when > searching (yes, the call to free_cache() is really the only difference in > the program). That's strange indeed. Can you come up with a short demo which displays the problem ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Mon Sep 16 19:50:53 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D85FE5C.2010402@lemburg.com> References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> Message-ID: <200209161850.53994@danielnaber.de> On Monday 16 September 2002 17:53, you wrote: > > index that calls free_cache() on every 50th file gets less matches > > when searching (yes, the call to free_cache() is really the only > > difference in the program). > > That's strange indeed. Can you come up with a short demo which > displays the problem ? Okay, this is not very short, as it seems you need a certain amount of data to trigger the problem. Call this script like this: ./FullText2.py /data/bigindex/test/ widget The first parameter is a directory, the second one a search term. Then look for "####" in the script and comment in the free_cache() call and run the script again with the same parameters and you should get less matches when free_cache is called, and the data files are also smaller. If it doesn't work I can send you an archive of about 30 HTML files that let you reproduce the problem . Regards Daniel -- http://www.danielnaber.de -------------- next part -------------- A non-text attachment was scrubbed... Name: FullText2.py Type: text/x-python Size: 3883 bytes Desc: not available Url : /mailman-archives/egenix-users/attachments/20020916/179a1fb0/FullText2-0139.py From mal at lemburg.com Mon Sep 16 22:55:08 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> Message-ID: <3D86371C.2030109@lemburg.com> Daniel Naber wrote: > On Monday 16 September 2002 17:53, you wrote: > > >>>index that calls free_cache() on every 50th file gets less matches >>>when searching (yes, the call to free_cache() is really the only >>>difference in the program). >> >>That's strange indeed. Can you come up with a short demo which >>displays the problem ? > > > Okay, this is not very short, as it seems you need a certain amount of data > to trigger the problem. Call this script like this: > > ./FullText2.py /data/bigindex/test/ widget > > The first parameter is a directory, the second one a search term. Then look > for "####" in the script and comment in the free_cache() call and run the > script again with the same parameters and you should get less matches when > free_cache is called, and the data files are also smaller. If it doesn't > work I can send you an archive of about 30 HTML files that let you > reproduce the problem . Thanks for the script. I can reproduce the problem here, but still don't understand what is causing it. The table index size is the same in both cases, the file sizes differs. This could relate to the way you store the data: using dictionaries of lists as values in the BeeDict. I'll have to investigate this some more. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Mon Sep 16 23:10:07 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] DateTime bus error on Solaris In-Reply-To: <20020910075928.GA3494@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> <20020910075928.GA3494@cise.ufl.edu> Message-ID: <20020917021007.GA23047@cise.ufl.edu> * N. Thomas [2002-09-10 03:59:28 -0400]: > > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine > > running Solaris 8 (SunOS 5.8). > > > > When I run any program that uses DateTime (or indeed, any module that > > calls it) I get the following error: > > > > $ python foo.py > > zsh: bus error python foo.py > > A bit of digging on Google tells me that it might possibly be a problem > with byte alignment on Sparc. I would like to check this, and pass the > "-mno-unaligned-doubles" flag to gcc when it compiles, how can I do this? This didn't seem to work. Anybody have any suggestions on how to debug this? thanks, thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From nthomas at cise.ufl.edu Mon Sep 16 23:49:14 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <20020910072923.GA2087@cise.ufl.edu> References: <20020910072923.GA2087@cise.ufl.edu> Message-ID: <20020917024914.GA23391@cise.ufl.edu> * N. Thomas [2002-09-10 03:29:23 -0400]: > I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running > Solaris 8 (SunOS 5.8). > > When I run any program that uses DateTime (or indeed, any module that calls > it) I get the following error: > > $ python foo.py > zsh: bus error python foo.py Thanks to a helpful python guru on #python, I was able to use gdb to track down the cause of the crash, and shed some more light on the situation. Here is the relevant info from gdb: Program received signal SIGSEGV, Segmentation fault. mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 333 _Py_NewReference(datetime); I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What could be causing this? thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From mal at lemburg.com Tue Sep 17 11:59:45 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <200209161614.10077@danielnaber.de> <3D85FE5C.2010402@lemburg.com> <200209161850.53994@danielnaber.de> <3D86371C.2030109@lemburg.com> Message-ID: <3D86EF01.8010300@lemburg.com> M.-A. Lemburg wrote: > Daniel Naber wrote: > >> On Monday 16 September 2002 17:53, you wrote: >> >> >>>> index that calls free_cache() on every 50th file gets less matches >>>> when searching (yes, the call to free_cache() is really the only >>>> difference in the program). >>> >>> >>> That's strange indeed. Can you come up with a short demo which >>> displays the problem ? >> >> >> >> Okay, this is not very short, as it seems you need a certain amount of >> data to trigger the problem. Call this script like this: >> >> ./FullText2.py /data/bigindex/test/ widget >> >> The first parameter is a directory, the second one a search term. Then >> look for "####" in the script and comment in the free_cache() call and >> run the script again with the same parameters and you should get less >> matches when free_cache is called, and the data files are also >> smaller. If it doesn't work I can send you an archive of about 30 HTML >> files that let you reproduce the problem . > > > Thanks for the script. I can reproduce the problem here, but > still don't understand what is causing it. The table index size > is the same in both cases, the file sizes differs. > > This could relate to the way you store the data: using dictionaries > of lists as values in the BeeDict. I'll have to investigate this > some more. Ok, I've tracked down the problem. There are two things to watch out for: 1. When modifying mutable values in place you have to explicitly reassign the dictionary item after all modifications have taken place. This is necessary to mark the item as modified so that a subsequent .commit() can write it back to the on-disk version, e.g. # get value listvalue = d['key'] # modify in place listvalue.append(1) # mark as modified d['key'] = listvalue 2. You should call .commit() before calling .free_cache() in order to free up more memory. .free_cache() will otherwise only remove items from the in-memory cache which have not been marked modified. Since you are mostly adding new items in your script, almost all entries are marked as modified, so the effect without .commit() is minimal. In the egenix-mx-base 2.1 final release I'll add a new parameter maxcachesize to BeeDicts which lets you tune the cache size on a per-object basis. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.naber at t-online.de Tue Sep 17 18:02:54 2002 From: daniel.naber at t-online.de (Daniel Naber) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] BeeDict memory usage In-Reply-To: <3D86EF01.8010300@lemburg.com> References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> Message-ID: <200209171702.54128@danielnaber.de> On Tuesday 17 September 2002 10:59, you wrote: > Ok, I've tracked down the problem. > > There are two things to watch out for: That helps, thanks! Indexing now needs 25% of the memory it used to need, but it's also 4 times as slow - but this had to happen I guess. I wonder how search engines like htdig can have such a fast indexing. It's probably because they have somehow heavily optimized their data structures for full-text indexing. Regards Daniel -- http://www.danielnaber.de From mal at lemburg.com Tue Sep 17 21:36:18 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:12 2006 Subject: [egenix-users] BeeDict memory usage References: <200209120301.11205@danielnaber.de> <3D86371C.2030109@lemburg.com> <3D86EF01.8010300@lemburg.com> <200209171702.54128@danielnaber.de> Message-ID: <3D877622.7010808@lemburg.com> Daniel Naber wrote: > On Tuesday 17 September 2002 10:59, you wrote: > > >>Ok, I've tracked down the problem. >> >>There are two things to watch out for: > > > That helps, thanks! Indexing now needs 25% of the memory it used to need, > but it's also 4 times as slow - but this had to happen I guess. I wonder > how search engines like htdig can have such a fast indexing. It's probably > because they have somehow heavily optimized their data structures for > full-text indexing. I think that the solution is to use a specialized key between the on-disk dictionary and the indexer -- often used terms should probably be kept in this cache and only written to disk at the very end. The fact that you can subclass the BeeDict class should help with this: you can easily implement your own caching strategy, e.g. for indexing you don't need .rollback transaction support, so a priority queue driven cache strategy probably fits better. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Tue Sep 17 22:44:40 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:13 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> Message-ID: <3D878628.9030001@lemburg.com> N. Thomas wrote: > * N. Thomas [2002-09-10 03:29:23 -0400]: > >>I am using egenix-mx-base-2.0.3, Python 2.1.1 on a Sun Sparc machine running >>Solaris 8 (SunOS 5.8). >> >>When I run any program that uses DateTime (or indeed, any module that calls >>it) I get the following error: >> >> $ python foo.py >> zsh: bus error python foo.py > > > Thanks to a helpful python guru on #python, I was able to use gdb to track > down the cause of the crash, and shed some more light on the situation. Here > is the relevant info from gdb: > > Program received signal SIGSEGV, Segmentation fault. > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > 333 _Py_NewReference(datetime); > > I'm assuming _Py_NewReference() is part of Python and not mxDateTime. What > could be causing this? This could have something to do with the free list used in mxDateTime. Try compiling mxDateTime without free list support (edit mxDateTime.c near the top and disable the two defines). If that helps, you're set. The bus error sounds very much like a compiler optimization bug to me. I've never heard of any bug report related to _Py_NewReference(). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nthomas at cise.ufl.edu Tue Sep 17 22:07:08 2002 From: nthomas at cise.ufl.edu (N. Thomas) Date: Fri Mar 31 16:33:13 2006 Subject: [egenix-users] Re: DateTime bus error on Solaris In-Reply-To: <3D878628.9030001@lemburg.com> References: <20020910072923.GA2087@cise.ufl.edu> <20020917024914.GA23391@cise.ufl.edu> <3D878628.9030001@lemburg.com> Message-ID: <20020918010708.GA13197@cise.ufl.edu> * M.-A. Lemburg [2002-09-17 21:44:40 +0200]: > > Program received signal SIGSEGV, Segmentation fault. > > mxDateTime_New () at mx/DateTime/mxDateTime/mxDateTime.c:333 > > 333 _Py_NewReference(datetime); > > > > This could have something to do with the free list used in mxDateTime. Try > compiling mxDateTime without free list support (edit mxDateTime.c near the > top and disable the two defines). Excellent! That worked! Thanks so much for your help! thomas -- N. Thomas nthomas@cise.ufl.edu Etiamsi occiderit me, in ipso sperabo From yasusii at lowlife.jp Wed Sep 18 22:48:08 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Mar 31 16:33:13 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 Message-ID: <20020918.214808.41630713.yasusii@lowlife.jp> I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux 7.3. It works well on the machine. But same binary displays warning message like bellow on other machines running Red Hat 7.3. $ cat hello print 'Hello!' $ ./cgipython hello 'import site' failed; use -v for traceback Hello! Same problem is reported on FreeBSD and Solaris 8 at Python Japanese users mailing list. From mal at lemburg.com Thu Sep 19 11:55:11 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:13 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> Message-ID: <3D8990EF.2020202@lemburg.com> Yasushi Iwata wrote: > I build mxCGIPython 0.5.0 binary with Python 2.2 on Red Hat Linux > 7.3. It works well on the machine. But same binary displays warning > message like bellow on other machines running Red Hat 7.3. > > $ cat hello > print 'Hello!' > $ ./cgipython hello > 'import site' failed; use -v for traceback > Hello! > > Same problem is reported on FreeBSD and Solaris 8 at Python Japanese > users mailing list. This could be caused by missing codecs. Please set the environment variable PYTHONVERBOSE and rerun the script to see the traceback. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From yasusii at lowlife.jp Thu Sep 19 20:38:27 2002 From: yasusii at lowlife.jp (Yasushi Iwata) Date: Fri Mar 31 16:33:13 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 In-Reply-To: <3D8990EF.2020202@lemburg.com> References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> Message-ID: <20020919.193827.71082838.yasusii@lowlife.jp> On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > This could be caused by missing codecs. Please set the environment > variable PYTHONVERBOSE and rerun the script to see the traceback. The traceback is: $ export PYTHONVERBOSE=x $ ./cgipython hello import site # frozen import os # frozen import posix # builtin import posixpath # frozen import stat # frozen import UserDict # frozen import copy_reg # frozen import types # frozen import __future__ # frozen 'import site' failed; traceback: Traceback (most recent call last): File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? IndexError: list index out of range Python 2.2.1 (#1, Sep 18 2002, 20:42:17) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] Copyright (c) 2001, 2002 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved. import __main__ # frozen Hello! -- SNIP -- From mal at lemburg.com Thu Sep 19 14:11:56 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:13 2006 Subject: [egenix-users] PROBLEM: mxCGIPython 0.5.0 References: <20020918.214808.41630713.yasusii@lowlife.jp> <3D8990EF.2020202@lemburg.com> <20020919.193827.71082838.yasusii@lowlife.jp> Message-ID: <3D89B0FC.9050700@lemburg.com> Yasushi Iwata wrote: > On Thu, 19 Sep 2002 10:55:11 +0200 you wrote: > > >>This could be caused by missing codecs. Please set the environment >>variable PYTHONVERBOSE and rerun the script to see the traceback. > > > The traceback is: > > $ export PYTHONVERBOSE=x > $ ./cgipython hello > import site # frozen > import os # frozen > import posix # builtin > import posixpath # frozen > import stat # frozen > import UserDict # frozen > import copy_reg # frozen > import types # frozen > import __future__ # frozen > 'import site' failed; traceback: > Traceback (most recent call last): > File "/tmp/Python-2.2.1/Lib/site.py", line 95, in ? > IndexError: list index out of range Interesting. This is the line causing the problem: # Append ./build/lib. in case we're running in the build dir # (especially for Guido :-) if os.name == "posix" and os.path.basename(sys.path[-1]) == "Modules": ... Looks as if sys.path is empty at the time site.py is loaded. I tried a similar setup (no PYTHONPATH set, no PYTHONHOME) on Linux: private/tmp> ./cgipython test 'import site' failed; use -v for traceback Hello World! ['.'] with test: import sys print 'Hello World!' print sys.path The problem goes away if you define the environment variable PYTHONPATH as empty. I'd say this is a bug in site.py; I can't see how it can assume that sys.path is always set. I've fixed this in Python CVS. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jds at kc.rr.com Fri Sep 20 22:34:02 2002 From: jds at kc.rr.com (Joe) Date: Fri Mar 31 16:33:14 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem Message-ID: <000e01c26117$59984a50$362c57d8@DELL4100> Hello everyone, I am using the ODBC windows module to connect to a MSSQL 2000 server, everything works except manual-transaction mode. I set it to clear_auto_commit (default), so I can use .commit() and .rollback(), and I get the Error: Attribute Error: commit. The docs say this means the database doesn't support transactions but I know this isn't the case. I have a perl script using DBI::ODBC that is able to use transactions. Do I need to recompile the module with certain flags to allow the module to recognize that the DB supports transactions? Any light that could be shed on this problem would be appreciated! Here's a code snippet that throws the AttributeError: import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') cursor = db.cursor() cursor.execute("update users set name='bob' where users_pk = 15") cursor.commit() cursor.close db.close -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20020920/050e6d4f/attachment-0139.htm From mal at lemburg.com Sat Sep 21 22:54:16 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:14 2006 Subject: [egenix-users] mx.ODBC.windows Transaction Problem References: <000e01c26117$59984a50$362c57d8@DELL4100> Message-ID: <3D8CCE68.7020207@lemburg.com> Joe wrote: > Hello everyone, > > I am using the ODBC windows module to connect to a MSSQL 2000 server, > everything works except manual-transaction mode. I set it to > clear_auto_commit (default), so I can use .commit() and .rollback(), and > I get the Error: Attribute Error: commit. The docs say this means the > database doesn't support transactions but I know this isn't the case. I > have a perl script using DBI::ODBC that is able to use transactions. Do > I need to recompile the module with certain flags to allow the module to > recognize that the DB supports transactions? connection.commit() will always succeed -- even on connections which don't support transactions. connection.rollback() will either raise an AttributeError or NotSupportedError is the connection does not support transactions. > Any light that could be > shed on this problem would be appreciated! Here's a code snippet that > throws the AttributeError: > > import mx.ODBC.Windows > > db = mx.ODBC.Windows.DriverConnect('DSN=test;uid=xxx;pwd=xxx') > cursor = db.cursor() > cursor.execute("update users set name='bob' where users_pk = 15") > cursor.commit() .commit() is a method on the connection object, not the cursor. When calling .commit on the connection you commit all work done with all cursors currently working on the active transaction and you implicitly start a new transaction (on all cursors still possibly open on the connection). > cursor.close > db.close -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Mon Sep 23 16:08:21 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Mar 31 16:33:14 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, here's a patch that allowed me to build and install mxExperimental on cygwin. I previously sent a message that is being held for moderator approval detailing the error messages I was getting when trying to install. I didn't do anything special when installing gmp on cygwin: I used the latest (4.1) and simply did './configure; make; make install'. The patch: Index: mxEXPERIMENTAL.py =================================================================== RCS file: /home/cvs/ysi/contrib/mxExperimental/mxEXPERIMENTAL.py,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** mxEXPERIMENTAL.py 19 Sep 2002 19:36:04 -0000 1.1 --- mxEXPERIMENTAL.py 23 Sep 2002 19:59:55 -0000 1.2 *************** *** 135,140 **** --- 135,148 ---- libraries=['gmp31'], library_dirs=['mx/Number/mxNumber/win32']), ] + elif sys.platform == 'cygwin': + ext_modules[len(ext_modules):] = [ + + mx_Extension('mx.Number.mxNumber.mxNumber', + ['mx/Number/mxNumber/mxNumber.c'], + include_dirs=['mx/Number/mxNumber'], + libraries=['gmp']), + ] else: ext_modules[len(ext_modules):] = [ From mark at mceahern.com Mon Sep 23 14:55:27 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Mar 31 16:33:15 2006 Subject: [egenix-users] mxExperimental on cygwin Message-ID: Hi, I'm trying to install mxExperimental in cygwin. I've attached the full output (stdout and stderr) from: python setup.py install below. I first installed gmp on cygwin (configure; make; make install) and that seemed to work fine. I can compile and run the example.c program from gmp's install docs. I have the gmp libraries in /usr/local/lib: $ ls -l /usr/local/lib total 2538 -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la I'm not sure whether the reason the setup.py is failing is because it can't find libgmp, but it looks like that. How do I tell mxExperimental's setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and solution)? Thanks, // mark running install running build running build_py creating build creating build/lib.cygwin-1.3.12-i686-2.2 creating build/lib.cygwin-1.3.12-i686-2.2/mx copying mx/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/Number.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number copying mx/Number/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number creating build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy copying mx/Tidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/LazyModule.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/Listing.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/URL.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL copying mx/URL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL creating build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL copying mx/URL/mxURL/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/UID.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID copying mx/UID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID creating build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/test.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID copying mx/UID/mxUID/__init__.py -> build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID running build_clib building 'libtidy' library creating build/temp.cygwin-1.3.12-i686-2.2 creating build/temp.cygwin-1.3.12-i686-2.2/libtidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/attrs.c:9: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/clean.c:47: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/config.c:17: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/entities.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/istack.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/lexer.c:34: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/localize.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/parser.c:10: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/pprint.c:13: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tags.c:14: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -DCOMPILING_TI DY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/libtidy/tidy.c:70: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here ar -cr build/temp.cygwin-1.3.12-i686-2.2/liblibtidy.a build/temp.cygwin-1.3.12-i686-2.2/libtidy/attrs.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/clean.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/config.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/entities.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/istack.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/lexer.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/localize.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/parser.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/pprint.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tags.o build/temp.cygwin-1.3.12-i686-2.2/libtidy/tidy.o running mx_autoconf macros to define: [] macros to undefine: [] running build_ext building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy creating build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Tidy/mxTi dy -Imx/Tidy/mxTidy/libtidy -I/usr/include/python2.2 -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o In file included from mx/Tidy/mxTidy/libtidy/htmltidy.h:12, from mx/Tidy/mxTidy/mxTidy.c:27: mx/Tidy/mxTidy/libtidy/platform.h:99: warning: redefinition of `uint' /usr/include/sys/types.h:65: warning: `uint' previously declared here gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy/mxTidy.o -Lmx/Tidy/m xTidy/libtidy -L/usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2. 2 -llibtidy -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Tidy/mxTidy/mxTidy.dll building 'mx.URL.mxURL.mxURL' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL creating build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/URL/mxURL -I/usr/include/python2.2 -c mx/URL/mxURL/mxURL.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL/mxURL.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/URL/mxURL/mxURL.dll building 'mx.UID.mxUID.mxUID' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID creating build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/UID/mxUID -I/usr/include/python2.2 -c mx/UID/mxUID/mxUID.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID/mxUID.o -L/usr/lib/pyth on2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -llibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/UID/mxUID/mxUID.dll building 'mx.Number.mxNumber.mxNumber' extension creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber creating build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DUSE_DL_IMPORT -Imx/Number/mx Number -I/usr/include/python2.2 -c mx/Number/mxNumber/mxNumber.c -o build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o mx/Number/mxNumber/mxNumber.c: In function `mxInteger_Getattr': mx/Number/mxNumber/mxNumber.c:632: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromLong': mx/Number/mxNumber/mxNumber.c:1712: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `_mxRational_FromFloat': mx/Number/mxNumber/mxNumber.c:1958: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_FromTwoObjects': mx/Number/mxNumber/mxNumber.c:2295: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxRational_Getattr': mx/Number/mxNumber/mxNumber.c:2530: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_New': mx/Number/mxNumber/mxNumber.c:3139: warning: label `onError' defined but not used mx/Number/mxNumber/mxNumber.c: In function `mxFloat_Getattr': mx/Number/mxNumber/mxNumber.c:3598: warning: label `onError' defined but not used gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o -L/ usr/lib/python2.2/config -Lbuild/temp.cygwin-1.3.12-i686-2.2 -lpython2.2 -ll ibtidy -o build/lib.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber.dll build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:399 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:435 : undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 : undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:333 : undefined reference to `__gmpz_set_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:690 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:725 : undefined reference to `__gmpz_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:942 : undefined reference to `__gmpz_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:943 : undefined reference to `__gmpz_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:944 : undefined reference to `__gmpz_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:945 : undefined reference to `__gmpz_tdiv_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Negative': /usr/local/include/gmp.h:1598: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Absolute': /usr/local/include/gmp.h:1503: undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Invert': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:948 : undefined reference to `__gmpz_com' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_And': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:949 : undefined reference to `__gmpz_and' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Or': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:950 : undefined reference to `__gmpz_ior' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Remainder': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:951 : undefined reference to `__gmpz_tdiv_r' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Divmod': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:952 : undefined reference to `__gmpz_tdiv_qr' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Xor': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:976 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:977 : undefined reference to `__gmpz_ior' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:980 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:983 : undefined reference to `__gmpz_com' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:985 : undefined reference to `__gmpz_and' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:988 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:103 3: undefined reference to `__gmpz_pow_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:104 2: undefined reference to `__gmpz_powm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:115 9: undefined reference to `__gmpz_root' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_gcd': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:126 1: undefined reference to `__gmpz_gcd' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_lcm': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:128 8: undefined reference to `__gmpz_lcm' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_jacobi': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:131 5: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_legendre': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:134 0: undefined reference to `__gmpz_jacobi' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:137 1: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_hamdist': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:144 9: undefined reference to `__gmpz_hamdist' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `farey_rational': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 8: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:178 9: undefined reference to `__gmpf_neg' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:179 4: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 7: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:180 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 0: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 4: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:181 5: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 3: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 4: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:182 5: undefined reference to `__gmpz_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 6: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 7: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:183 8: undefined reference to `__gmpf_mul' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 1: undefined reference to `__gmpf_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 4: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:184 6: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 3: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:185 7: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 0: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 4: undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:186 8: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 4: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 5: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:187 7: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:188 0: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFareyApprox': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 5: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:190 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 3: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:191 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:193 8: undefined reference to `__gmpf_get_prec' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 1: undefined reference to `__gmpf_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 2: undefined reference to `__gmpf_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 3: undefined reference to `__gmpf_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 4: undefined reference to `__gmpf_trunc' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 5: undefined reference to `__gmpz_set_f' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 6: undefined reference to `__gmpf_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:194 9: undefined reference to `__gmpz_set_ui' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 0: undefined reference to `__gmpz_mul_2exp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:195 3: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:201 5: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:202 9: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:203 0: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 4: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:204 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 3: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 7: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:205 8: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 6: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 7: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 8: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:206 9: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:207 0: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 2: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 4: undefined reference to `__gmpq_set_z' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 6: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:209 8: undefined reference to `__gmpz_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 2: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 3: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 4: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 6: undefined reference to `__gmpq_add' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:210 8: undefined reference to `__gmpq_sub' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:163 9: undefined reference to `__gmpq_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 2: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 3: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 4: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 5: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:211 9: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 0: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 1: undefined reference to `__gmpq_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 2: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:212 3: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:170 7: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:172 4: undefined reference to `__gmpq_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:165 2: undefined reference to `__gmpq_set_z' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoIntegers': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_FromTwoObjects': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:168 9: undefined reference to `__gmpq_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:169 0: undefined reference to `__gmpq_canonicalize' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 6: undefined reference to `__gmpq_set_num' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 7: undefined reference to `__gmpq_set_den' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:166 8: undefined reference to `__gmpq_canonicalize' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:237 3: undefined reference to `__gmpz_sizeinbase' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:238 2: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:239 1: undefined reference to `__gmpz_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:240 6: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:307 : undefined reference to `__gmpz_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:258 8: undefined reference to `__gmpq_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:262 3: undefined reference to `__gmpq_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 6: undefined reference to `__gmpq_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 7: undefined reference to `__gmpq_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 8: undefined reference to `__gmpq_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:283 9: undefined reference to `__gmpq_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:160 1: undefined reference to `__gmpq_init' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Negative': /usr/local/include/gmp.h:1674: undefined reference to `__gmpq_set' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromString': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:327 3: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:330 6: undefined reference to `__gmpf_set_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_FromObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:320 0: undefined reference to `__gmpf_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:321 3: undefined reference to `__gmpf_set_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:325 2: undefined reference to `__gmpf_set_q' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsStringObject': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:342 2: undefined reference to `__gmpf_get_str' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:347 5: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Getattr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:358 8: undefined reference to `__gmpf_get_prec' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Compare': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:364 0: undefined reference to `__gmpf_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:365 3: undefined reference to `__gmpf_cmp' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Add': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 6: undefined reference to `__gmpf_add' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Subtract': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 7: undefined reference to `__gmpf_sub' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Multiply': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 8: undefined reference to `__gmpf_mul' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Divide': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:384 9: undefined reference to `__gmpf_div' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Negative': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 0: undefined reference to `__gmpf_neg' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Absolute': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:313 3: undefined reference to `__gmpf_init2' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:385 1: undefined reference to `__gmpf_abs' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `initmxNumber': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 2: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 4: undefined reference to `__gmpz_set_si' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:452 5: undefined reference to `__gmpz_set_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:282 : undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyLong': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:562 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:523 : undefined reference to `__gmpz_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:505 : undefined reference to `__gmpz_cmp' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:510 : undefined reference to `__gmpz_get_si' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Str': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_Repr': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:537 : undefined reference to `__gmpz_get_str' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_sqrt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:113 3: undefined reference to `__gmpz_sqrt' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_has_root': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 3: undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 4: undefined reference to `__gmpz_root' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:118 7: undefined reference to `__gmpz_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_power': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:120 1: undefined reference to `__gmpz_perfect_power_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_is_perfect_square': /usr/local/include/gmp.h:1614: undefined reference to `__gmpn_perfect_square_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_prime': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:123 6: undefined reference to `__gmpz_probab_prime_p' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_over': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:139 7: undefined reference to `__gmpz_bin_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxInteger_popcount': /usr/local/include/gmp.h:1630: undefined reference to `__gmpn_popcount' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:161 4: undefined reference to `__gmpq_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxRational_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:234 2: undefined reference to `__gmpq_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Free': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:314 9: undefined reference to `__gmpf_clear' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyFloat': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_AsPyInt': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:337 2: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxFloat_Hash': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:339 1: undefined reference to `__gmpf_get_d' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Factorial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:438 3: undefined reference to `__gmpz_fac_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Binomial': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:440 9: undefined reference to `__gmpz_bin_uiui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumber_Fibonacci': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:269 : undefined reference to `__gmpz_init' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:443 5: undefined reference to `__gmpz_fib_ui' build/temp.cygwin-1.3.12-i686-2.2/mx/Number/mxNumber/mxNumber/mxNumber.o: In function `mxNumberModule_Cleanup': /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 1: undefined reference to `__gmpz_clear' /home/mark/proj/ysi/contrib/mxExperimental/mx/Number/mxNumber/mxNumber.c:450 2: undefined reference to `__gmpz_clear' collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 From mal at lemburg.com Tue Sep 24 10:55:38 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:15 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D901A7A.8090305@lemburg.com> Mark McEahern wrote: > Hi, I'm trying to install mxExperimental in cygwin. I've attached the full > output (stdout and stderr) from: > > python setup.py install > > below. > > I first installed gmp on cygwin (configure; make; make install) and that > seemed to work fine. I can compile and run the example.c program from gmp's > install docs. I have the gmp libraries in /usr/local/lib: > > $ ls -l /usr/local/lib > total 2538 > -rw-r--r-- 1 mark None 2597856 Sep 19 15:32 libgmp.a > -rw-r--r-- 1 mark None 645 Sep 19 15:32 libgmp.la > > I'm not sure whether the reason the setup.py is failing is because it can't > find libgmp, but it looks like that. How do I tell mxExperimental's > setup.py that libgmp is in /usr/local/lib, assuming that's the problem (and > solution)? First: are you using the beta1 of egenix-mx-experimental ? If not, please try that version first. setup.py should look in /usr/local/lib per default, so no special options are needed. Makes me think: I should probably ship a new beta of that package... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mark at mceahern.com Tue Sep 24 09:11:00 2002 From: mark at mceahern.com (Mark McEahern) Date: Fri Mar 31 16:33:15 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D901A7A.8090305@lemburg.com> Message-ID: [M.-A. Lemburg] > First: are you using the beta1 of egenix-mx-experimental ? > If not, please try that version first. setup.py should look in > /usr/local/lib per default, so no special options are needed. > > Makes me think: I should probably ship a new beta of that > package... I'm sorry, I should have specified what version I was using in my original email. I'm using this version: http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz Is that what you're referring to as beta1? I assume you saw the patch I posted to mxEXPERIMENTAL.py where the distutils package is defined. I was able to install it successfully on cygwin simply by explicitly specifying the library: http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. html Of course, I'm not a master at using either gcc or distutils, so there may be an obvious reason why my patch is braindead. I really appreciate this package. In particular I'm using mxTidy and it works dandy. Thanks! Cheers, // mark - From mal at lemburg.com Tue Sep 24 16:57:42 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:15 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D906F56.6010701@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg] > >>First: are you using the beta1 of egenix-mx-experimental ? >>If not, please try that version first. setup.py should look in >>/usr/local/lib per default, so no special options are needed. >> >>Makes me think: I should probably ship a new beta of that >>package... > > > I'm sorry, I should have specified what version I was using in my original > email. I'm using this version: > > http://www.egenix.com/files/python/egenix-mx-experimental-0.6.0.tar.gz This is the latest beta: http://www.egenix.com/files/python/egenix-mx-experimental-0.7.0b1.tar.gz > Is that what you're referring to as beta1? I assume you saw the patch I > posted to mxEXPERIMENTAL.py where the distutils package is defined. I was > able to install it successfully on cygwin simply by explicitly specifying > the library: > > > http://lists.egenix.com/mailman-archives/egenix-users/2002-September/000126. > html > > Of course, I'm not a master at using either gcc or distutils, so there may > be an obvious reason why my patch is braindead. Not at all: the explicit mention is what was missing in 0.6.0 :-) > I really appreciate this package. In particular I'm using mxTidy and it > works dandy. Thanks! You're welcome. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From marklists at mceahern.com Tue Sep 24 11:13:16 2002 From: marklists at mceahern.com (Mark McEahern) Date: Fri Mar 31 16:33:15 2006 Subject: [egenix-users] mxExperimental on cygwin In-Reply-To: <3D906F56.6010701@lemburg.com> Message-ID: [M.-A. Lemburg [mailto:mal@lemburg.com]] >Not at all: the explicit mention is what was missing in 0.6.0 :-) I think part of the reason I was unsure about the validity of my hack for cygwin is that it was entirely unnecessary on Linux. That is, without explicitly mentioning gmp (by the way, is that pronounced "gimp"?) in the libraries, it worked on Linux (RH 7.3), so no mods were necessary with 0.6.0. Cheers, // m From mal at lemburg.com Tue Sep 24 18:23:55 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:15 2006 Subject: [egenix-users] mxExperimental on cygwin References: Message-ID: <3D90838B.8040609@lemburg.com> Mark McEahern wrote: > [M.-A. Lemburg [mailto:mal@lemburg.com]] > >>Not at all: the explicit mention is what was missing in 0.6.0 :-) > > > I think part of the reason I was unsure about the validity of my hack for > cygwin is that it was entirely unnecessary on Linux. That is, without > explicitly mentioning gmp (by the way, is that pronounced "gimp"?) No, GIMP is a graphics tool. > in the > libraries, it worked on Linux (RH 7.3), so no mods were necessary with > 0.6.0. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:14:10 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:15 2006 Subject: [egenix-users] ANN: eGenix.com mx BASE Extension Package 2.0.4 Message-ID: <3D91E0D2.3040702@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx BASE Extension Package for Python Version 2.0.4 Open Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx BASE Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as fast text searching, date/time processing and high speed datatypes. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms. You can write applications which use the tools on Windows and then run them on Unix platforms without change due to the consistent platform independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. ________________________________________________________________________ WHAT'S NEW ? The RPM packages were updated to install to /usr/ instead of /usr/local/ to comply with the Linux Standard Base (LSB) and to be compatible with the Python RPMs which are available from python.org. As always we are providing precompiled versions of the package for Windows and Linux as well as sources which allow you to install the package on all other supported platforms. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. Note that even though Python 2.1+ has its own weak reference implemetation, this package can be used to write applications which also work on Python 1.5.2 and 2.0. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE package comes with a Python 2.0 style license, which means that you can use it in both commercial and non-commercial settings without fee or charge. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal at lemburg.com Wed Sep 25 19:13:52 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:15 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 Message-ID: <3D91E0C0.5060407@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx EXPERIMENTAL Extension Package for Python Version 0.7.0 Experimental Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx Experimental Extensions for Python are a collection of alpha and beta quality software tools for Python which will be integrated into the other mx Extension Packages after they have matured to professional quality tools. Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. ________________________________________________________________________ WHAT'S NEW ? This release fixes a few minor bugs and solves the distutils problem with mxNumber. It also comes with an updated distutils setup which installs the RPMs into /usr/ rather than /usr/local/. ________________________________________________________________________ EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: mxNumber - Python Interface to GNU MP Number Types mxNumber provides direct access to the high performance numeric types available in the GNU Multi-Precision Lib (GMP). This library is licensed under the LGPL and runs on practically all Unix platforms. eGenix.com has ported the GMP lib to Windows, to also provide our Windows users with the added benefit of being able to do arbitrary precision calculations. The package currently provide these numerical types: 1. Integer(value) -- arbitrary precision integers much like Python longs only faster 2. Rational(nom,denom) -- rational numbers with Integers as numerator and denominator 3. Float(value[,prec]) -- floating point number with at least prec bits precision 4. FareyRational(value, maxden) -- calculate the best rational represenation n/d of value such that d < maxden mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) mxTidy provides a Python interface to a thread-safe, library version of the HTML Tidy. command line tool. HTML Tidy helps you to cleanup coding errors in HTML and XML files and produce well-formed HTML, XHTML or XML as output. This allows you to preprocess web-page for inclusion in XML repositories, prepare broken XML files for validation and also makes it possible to write converters from well-known word processing applications such as MS Word to other structured data representations by using XML as intermediate format. mxURL - A URL Datatype mxURL provides a new datatype for storing and manipulating URL values as well as a few helpers related to URL building, encoding and decoding. The main intention of the package is to provide an easy to use, fast and lightwheight datatype for Universal Resource Locators (note the W3C now calls these URIs). mxUID - A UID Datatype mxUID provides a fast mechanism for generating universal identification strings (UIDs). The intent is to make these UIDs unique with high probability in order to serve as object or data set identifiers. A typical use lies in generating session IDs. Other areas where unique IDs play an important role are RPC-implementations, ORBs, etc. ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/ Note that in order to use the eGenix.com mx EXPERIMENTAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? The EXPERIMENTAL packages uses different licenses in its subpackages. Please refer to the subpackage documentation for details. Some of them may be integrated into the BASE package, others will be integrated into the COMMERCIAL package. The package comes with full source code ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal at lemburg.com Wed Sep 25 19:14:33 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:15 2006 Subject: [egenix-users] ANN: eGenix.com mxODBC Python Database Interface Version 2.0.5 Message-ID: <3D91E0E9.3040309@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Interface for Python 1.5.2 - 2.2 Version 2.0.5 Full Source Python extension providing ODBC connectivity to Python applications on Windows, Unix abd Linux ________________________________________________________________________ WHAT IS IT ?: The mxODBC Database Interface allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux -- using just one interface to program against for all supported databases and platforms. This makes mxODBC the ideal basis for writing cross-platform database programs and utilities. mxODBC is included in the eGenix.com mx COMMERCIAL Extension Package for Python, the commercial part of the eGenix.com mx Extension Series, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. See http://www.egenix.com/ for details. ________________________________________________________________________ WHAT'S NEW ? The 2.0.5 version introduces work-arounds for bugs in various ODBC drivers to enhance the compatibility of mxODBC with Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server drivers. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I DOWNLOAD IT ? The download archives and instructions for installing the package can be found at: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Packages Note that in order to use the eGenix.com mx COMMERCIAL package you will first need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHERE CAN I BUY LICENSES ? mxODBC is free for non-commercial use. Commercial users have to buy licenses for continued use after a 30-day evaluation period. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BuyLicenses for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about our support offerings. ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Jim.Vickroy at noaa.gov Wed Sep 25 15:57:18 2002 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Mar 31 16:33:15 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> Message-ID: <3D92232E.402E4F74@noaa.gov> I have not been able to find v 0.7.0 on the download page. "M.-A. Lemburg" wrote: > ________________________________________________________________________ > > ANNOUNCING: > > eGenix.com mx EXPERIMENTAL Extension Package for Python > Version 0.7.0 > > Experimental Python extensions providing important and useful > services for Python programmers. > > ________________________________________________________________________ > > WHAT IS IT ?: > > The eGenix.com mx Experimental Extensions for Python are a collection > of alpha and beta quality software tools for Python which will be > integrated into the other mx Extension Packages after they have > matured to professional quality tools. > > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > ________________________________________________________________________ > > WHAT'S NEW ? > > This release fixes a few minor bugs and solves the distutils > problem with mxNumber. It also comes with an updated distutils > setup which installs the RPMs into /usr/ rather than /usr/local/. > > ________________________________________________________________________ > > EGENIX.COM MX EXPERIMENTAL PACKAGE OVERVIEW: > > mxNumber - Python Interface to GNU MP Number Types > > mxNumber provides direct access to the high performance numeric > types available in the GNU Multi-Precision Lib (GMP). This > library is licensed under the LGPL and runs on practically all > Unix platforms. eGenix.com has ported the GMP lib to Windows, to > also provide our Windows users with the added benefit of being > able to do arbitrary precision calculations. > > The package currently provide these numerical types: > > 1. Integer(value) -- arbitrary precision integers much like > Python longs only faster > 2. Rational(nom,denom) -- rational numbers with Integers as > numerator and denominator > 3. Float(value[,prec]) -- floating point number with at least > prec bits precision > 4. FareyRational(value, maxden) > -- calculate the best rational represenation > n/d of value such that d < maxden > > mxTidy - Interface to HTML Tidy (HTML/XML cleanup tool) > > mxTidy provides a Python interface to a thread-safe, library > version of the HTML Tidy. command line tool. > > HTML Tidy helps you to cleanup coding errors in HTML and XML > files and produce well-formed HTML, XHTML or XML as output. This > allows you to preprocess web-page for inclusion in XML > repositories, prepare broken XML files for validation and also > makes it possible to write converters from well-known word > processing applications such as MS Word to other structured data > representations by using XML as intermediate format. > > mxURL - A URL Datatype > > mxURL provides a new datatype for storing and manipulating URL > values as well as a few helpers related to URL building, encoding > and decoding. > > The main intention of the package is to provide an easy to use, > fast and lightwheight datatype for Universal Resource Locators > (note the W3C now calls these URIs). > > mxUID - A UID Datatype > > mxUID provides a fast mechanism for generating universal > identification strings (UIDs). The intent is to make these UIDs > unique with high probability in order to serve as object or data > set identifiers. > > A typical use lies in generating session IDs. Other areas where > unique IDs play an important role are RPC-implementations, > ORBs, etc. > > ________________________________________________________________________ > > WHERE CAN I DOWNLOAD IT ? > > The download archives and instructions for installing the packages can > be found at: > > http://www.egenix.com/ > > Note that in order to use the eGenix.com mx EXPERIMENTAL package you > will first need to install the eGenix.com mx BASE package which can > be downloaded from the same location. > > ________________________________________________________________________ > > WHAT DOES IT COST ? > > The EXPERIMENTAL packages uses different licenses in its subpackages. > Please refer to the subpackage documentation for details. Some of them > may be integrated into the BASE package, others will be integrated > into the COMMERCIAL package. > > The package comes with full source code > > ________________________________________________________________________ > > WHERE CAN I GET SUPPORT ? > > Commercial quality support for these packages is available from > eGenix.com. Please see > > http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support > > for details about our support offerings. > > ________________________________________________________________________ > > Enjoy, > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Company & Consulting: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Thu Sep 26 10:50:34 2002 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:15 2006 Subject: [egenix-users] ANN: eGenix.com mx EXPERIMENTAL Package 0.7.0 References: <3D91E0C0.5060407@lemburg.com> <3D92232E.402E4F74@noaa.gov> Message-ID: <3D92BC4A.2000105@lemburg.com> Jim Vickroy wrote: > I have not been able to find v 0.7.0 on the download page. http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxEXPERIMENTAL and little further down, the page lists the download links. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/